Closes #587. Cloudflare Workers uses esbuild under the hood to bundle the code, and esbuild always tries to bundle in imports, even if they are dynamic imports. This means that, if the dynamic import is done to a dependency that is not available, it will error, like

ERROR: Could not resolve "@react-email/render"

This means that it breaks our shanenigans with try-catch on the import for render and avoiding it being imported without the react option.

The thing is that, as this comment from Evan Wallace mentions evanw/esbuild#3216 (comment), esbuild has heuristics to not error when there is some sort of error handling for the dynamic import, which also includes the sort of syntax we are using. The reason it still fails, is because we are building with tsup for a target bellow es2017 which doesn't support async-await, and so for the built code to work it uses a different sort of generator syntax.

return __async(this, null, function* () {
  const data = yield this.resend.get("/api-keys");
  return data;
});

This isn't really caught by the heuristics for esbuild, so this pull request handles the errors with .then/.catch. This does seem to do the trick quite from what I've tested trying to deploy something with Cloudflare Workers in the preview version of this pull request.

Summary by cubic

Fixes esbuild bundling failures with dynamic imports in Cloudflare Workers by replacing async/await with a then/catch wrapper and centralizing rendering. Optional @react-email/render no longer breaks builds when not installed.

• Bug Fixes

  • Use then/catch dynamic import to satisfy esbuild’s error-handling heuristic, preventing eager bundling.
  • Eliminates “Could not resolve '@react-email/render'” when the dependency is absent.

• Refactors

  • Added src/render.ts with a single render(node) helper.
  • Updated Emails and Batch to use the shared render and removed per-class render caching.